
Semantics in 



iatabase must meet the 
a variety of users, 
step when the shared 
ed, the needs of each 
considered separately 
m of database designs in- 
or each class is formed, 
iualized designs are then 
!b form an integrated data- 
that satisfies the require- 
of all classes of users. Ordinari- 
ly, this shared database is too complex 
for typical users to manipulate. For 
this reason, it is desirable to provide 
the users with interfaces that give them 
only information that is relevant to 
them. 

In shared relational databases, 
which are the subject of this article, 
this is done by defining views for each 
class of users. Views represent simpli- 
fied models of the database, and users 
can express queries and updates 
against them. How to handle queries 
expressed against views is well under- 
stood: The user's query is composed 
with the view definition so as to obtain 
a query that can be executed on the 
underlying database.* 
Similarly, updates expressed against 
view have to be translated into up- 
that can be executed on the un- 



derlying database. This problem has , 
been considered by many researchers, 
including fiancilhon and Spyratos 1 
and Dayal and Bernstein. 2 The dif- 
ficulty is that a solution to this prob- 
lem is inherently ambiguous. My ap- 
proach involves imposing syntactic 
criteria on the view update trans- 
lations, enumerating the alternative 
translations that satisfy these criteria, 3 
and then, at view definition time, using 
semantics to choose among these alter- 
natives. 

Since in the common model of rela- 
tional databases 4 the view is only an 
uninstantiated window onto the data- 
base, any updates specified against the 
database view must be translated into 
updates against the underlying data- 
base. The updated database state then 
induces a new view state, and it is desir- 
able that the new view state look as 
much as possible as if the user had per- 
formed the update directly on it. The 
update process is described by the 
following diagram: 




The author b currently in aa fa t i nt professor 
of cfflBpmef sqcdces el the University of Tens 
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The initial database state, DB, is 
mapped by means of the view, V % into 
view state V{DB). The user specifies 
update U against this view state to ob- 
tain hew vie* state U{ V{DB) ). To 
have a permanent effect, the view up-, 
date, C/, must be translated into a 
database. update sequence. The cor- 
responding (translated) database up- 
date sequence. Ti U) , is performed on 
the database to obtain database state 
T(U)iDB). which we will also call 
DB' With the new database state, 
DB'\ the new view state is V{DB' ). 
We say that this translation from view- 
update U to database update se- 
quence T{ V) has no side effects in the 
view if V[DB) = U{V{ DB)) . that 
is, if the view has changed precisely in 
accordance with the user's request. 
. Side effects are undesirable and are to 
be avoided whenever possible. In fact, 
no side effects occur in translating up- 
dates expressed against views that con- 
sist solely of the relational operators 
sekrt and project. However, in some 
cases, updates expressed against views 
that involve Joins (the operators that 
link relations in relational databases) 
cannot be translated unless some side 
effects are permitted. 

The question is, given a view update 
U, what is the correct database update 
sequence Ti U)l Our goal is to find a 
translator T that supplies a T(U) for 
each valid U. This translator is a func- 
. tional. mce it maps from functions 
[U] into other functions IT(U)\. It is 
based on the database definition and 
the view definition, as well as the 
semantics of the problem. Such a 
translator should be chosen in advance 
by an expert so that updates supplied 
by users can be performed without 
ambiguity. That is, we want to resolve 
any ambiguity completely through the 
choke of a view update translator at 
view definition time. 

The choke of a translator depends 
on a characterization of the set of 
possible translators. We characterize 
this set of translators by enumerating 
the possible translations for each view 
update request. In the diagram above, 



database update sequence T[U) is a 
translation of the view update request 
U. For each view update request U, the 
t ranslator Tchooses a database update 
sequence T(U) to implement the re- 
quest on the database. There may be 
zero translations, one translation, or 
many translations T(U) correspond- 
ing to any given update request U. 
since the desired view state can corre- 
spond to many database states. If there 
is precisely one update translation, we 
should use that one. If there are many 
translations, we need to choose one. 
Translations that involve the simplest 
changes to the database are probably 
better than those that involve more 
complex changes to the database. 
Using criteria based on this idea, we 
can reduce this ambiguity, but not elim- 
inate it. We can, however, enumerate 
the various translation alternatives. 

On the other hand, if there are no 
translations T( U) corresponding to a 
given update request, it is because 
there are no database states corre- 
sponding to the desired view state: In 
this case, the view state may not be 
achievable because the user's request 
implies additional changes that affect 
that view state. If we allow such addi- 
tional changes, which are side effects 
in the view, there may be translations 
T{U) that correspond to the elabo- 
rated view update U. 



View update translation 



Definitions. We need to define a f ew 
terms to explain the process of transla- 
tion of view updates into database up- 
dates, w a domain is a finite set of 
values. A relation schema is a tagged 
set of domains and a set of constraints 
that tuples in the relation must satisfy. 
The tags are the attribute names of 
the relation. A tuple is a tagged set of 
values; one value is drawn from each 
respective domain. (In the example 
view and database diagrams below, tu- 
ples are read horizontally and the at- 
tributes are the columns.) The exten- 



sion of a relation is the set of tuples in 
the relation. 

Functional dependencies and key 
dependencies are examples of con- 
straints; A key dependency indicates 
-that there is at most one tuple with any 
given values for the attributes in the 
key. (A key can be thought of as a 
•unique identifier for a particular rec-* 
ord;) A functional dependency is a 
generalization of the concept of a key ' 
dependency: We say that the attributes 
in set A functionally determine the at- 
tributes in set Y (written X - Y) if 
whenever two tuples have matching 
values for all attributes in X % they also 

have matching values for all attributes 

inY ^ . .. * * 

A database schema is a set of rela-^ 
tion schemata; indexed by relation 
name. A database extension is a set of 
relation extensions; there is one data- 
base extension for each relation in the ' 
database schema. 

A database view definition is a map- 
ping whose domain is the set of all rela- 
tion extensions for a given database f 
schema. The range of a database view ~ 
definition is also a set of relation exten- 
sions for a schema specific to the view 
definition. The mapr ing from the data- 
base that is the domain of that view to 
the relation in the range of the view is 
defined by a type of database quay. 
The view extension is the result of the 
database query that defines the view 
when performed on the underlying 
database that is the domain of the 
view. 

Views are defined by database 
queries. There are few restrictions on 
the nature of view definitions for views 
defined only for queries. But we must 
impose significant restrictions on 
views that we want to be able to up- 
date. For example, it is undesirable to 
update through views that include ag- 
gregations.* Consider an employee 

*An n-ory function / whose domain is a fmile 
power set is naonotoaic if (v) (fij sS/)- 
AR\->.Jt n ) S JlSi >.. JS n ). Select, project. 
Jofa rod oaioa of relations are morotcnk func- 
tions. The eetflfiffeuuje operator and aggrega- 
tiom are nonmonotonic. My theory docs not 
support views thai are c 
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relation with Employee and Depart- 
ment attributes, and a Department 

. view with Department and Number of 
employees attributes. The view update 
request to increment the number of j 
employees jn the Computer depart-., 

i; mem would result in the need to add an 
unknown employee to the Employee. , 

^relation. A request to decrement the v 
number of employees in the Toy. de- 
partment would require the computer ; 
to choose an employee to fire— a deci- 
sion best done by some person. 



relation. For example, we may want to 
make available a view of the Employee 
relation that .does riot include the 
salary attribute: > . 



mm 





Operators. The relational operators 
select, project, and join are more 
suitable than some of the other rela- 
tional operators (for example, divide 
and set difference) for denning up- 
datable views. The select operator ex- 
tracts the tuples from a relation that 
satisfy the selection condition. The 
tuples that do not satisfy the selection 
condition do not appear in the view. 
For example, given the Employee rela- 
tion shown above, we can define a 
view for the manager of the Toy 
department thai selects only employ- 
ees in the Toy department: 




The project operator extracts the 
desired attributes from each tuple in a 
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The join operator /combines two 
relations, and in so doing/combines 
tuples with matching attribute values'. 
If we take the join of the Employee 
and Manager relations above, we ob- 
tain the following view: 



(too 



Toy 



Htufiag 




: The union operator combines two 
ior more relations with the same 
schema definition into a single relation 
with the same schema definition. The 
union operator is commonly used in 
distributed databases to combine the 
partitioned components of the rela- 
tion. For example, consider a com- 
pany with three locations, Boston, 
Palo Alto, and Austin. It has employ- 
ee records containing name, depart- 
ment, and location, which are stored 
partitioned by location. A corporate 
manager might be given the combined 
view (the "Corporate employee 
view," below) that is the union of the 
three location-defined employee rela- 
tions, which follow: 



mm 
mm 
mm 



The select, project, join, and union 

operators have the interesting relation- 
ship illustrated by the following dia- 
gram. Select and project extract infor- 
mation from a -single relation. Union 
and join combine information from ^ 
more than one relation to form a single . 
relation * Select and union are horizon- - 
tal operators that refer to collections of 
tuples. Project and join are vertical 
operators that refer to attribute 3. 





Constraints on views and databases. 

The constraints on the database and 
view are as important for view update 
translation as the operators that define 
the view. The constraints 1 discus in 
this article are key dependencies (in 
which each tuple in a relation has a 
unique key) and inclusion dependen- 
cies on join fields (such as the 
specification that each employee must 
be in a department that exists in the 
Department relation). 

Other dependencies can also cause 
problems in view update translation. 
An example of such dependencies is an 
explicit functional dependency* In an 
explicit functional dependency, one or 
more of the attributes in a tuple can be 
computed based on the values of some 
other attributes in that tuple. One 
seemingly innocuous explicit func- 
tional dependency holds in the follow- 
ing relation: 
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In the Orders relation shown above, 
the price times the.quantity equals the 
i total. The view containing item, price,: 
and quantity fields (but not trie final 
field— total) appears below: 




A change to quantity or price implies 
some change to the total for that tuple. 
My r approach does not handle con- 
straints that, unlike functional de- 
pendencies, can be open ended arid 
f arbitrarily difficult to compute. 'For 
example, it is possible jn some ap- 
proaches to imbed NP-complete, or 
incomputable, problems as explicit 
functional dependencies. I require in- 
stead that any combination of values 
forming the attributes for a tuple in 
any one relation must be acceptable in 
some database state that satisfies the 
constraints for the schema under con- 
sideration. This restriction is stronger 
than merely eliminating explicit func- 
tional dependencies. 

A database update can be made 
directly against the database, provided 
it satisfies the constraints on the 
database. A view update is merely an 
update that is described against the 
view, but it must be translated into a 
sequence of database updates in order 
to be executed. There may be several 
candidate sequences of database up- 
dates corresponding to one view up- 
date. We call these sequences of data- 
base updates the translations of the 
view update request. We say that a 
translation is valid if it performs the 
view update as requested. 

For updates through select and pro- 
ject views, we require that the new view 
extension be precisely the result of per- 
forming the view update on the old 



view extension, as if the view in ques- 
tion were an ordinary relation. It may 
-v not be possible to perform updates 
through views that include joins 
/ without additional changes occurring 
; in. the view. 9 These view side effects 
ate a result of functional dependencies 
that require that changes requested in 
the view tuples be consistent with the 
remainder of the database. The under- 
lying tuples corresponding to a view 
tuple are the database tuples with keys 
matching the keys that appear in the 
view tuple., The side effects occur if 
view tuples share corresponding un- 
derlying tuples that undergo updates. 

Requiring that a translation be valid 
is not sufficient for our purposes— it is 
only a first step. I have defined five ad- 
ditional criteria that the translations 
: must satisfy. 3 These criteria proscribe 
(I) database side effects, (2) multiple 
changes to the same database tuple, (3); 
unnecessary database changes, (4) re- 
placements that can be simplified, arid 
(5) delete-insert pairs on the same rela- 
tion. The criteria are used to obtain 
only the simplest (or a minimal num- 
ber of) view update translations. 

A view update translator is a map- 
ping from view update requests into 
translations of these view update re- 
quests. A translator takes the user's 
view update requests and translates 
them inn database update requests 
that can be processed by the database 
system. Thus, a view update trans- 
lation facility would be a useful ad- 
junct to a database system that has » 
view definition facility. 

Various approaches to 
the view update 
problem 

Furtado and Casanova 10 provide a 
good overview of the view update 
problem. They do not propose any 
new solutions, but they do dearly ex- 
plain previous approaches. They com- 
plain that "a common tendency is to 
define views only for query and 
authorization purposes, and after- 



wards try to solve the problems created 
by view updated (They] fed that the 
update requirements should be con- 
sidered fromthe start...." , ° 

Oayal and Bernstein 2 provide a 
strong theoretical foundation for work 
■ on this problem. They provide some 
' algorithms for translating a restricted 
class of view updates. They define a 
-unique^ 

tioh, ami the translator is based solely ' 
on structural considerations. The sec- 
tion below tiUed "Examples of update 
operations commonly performed on 
databases and views" shows how 
structural considerations alone are in- 
sufficient to choose a view update 
translator. *V / 

5 Davidson and Kaplan I 1 - 12 consider V 
the related problem of natural lan- 
guage updates to databases. Their ap- 
proach involves ran; incomplete 
meration of translations and jislis^ 
heuristics to choose one of these trai& ' V ' 
lations. My approach involves a com- .... 
plete enumeration of translations and 
uses semantics supplied at view defini- 
tion time to choose a translator for . 
that view definition that will handle all ' 
view updates. 

Bancilhon and Spyratos 1 prove a 
mathematically elegant relationship 
between view update translators and 
constant view complements. Two 
views are complementary if together 
they supply sufficient information to 
determine the entire database state. 
Bancilhon and Spyratos show that a 
unique view update translator exists 
for a given view when a complemen- 
tary view is chosen to be held constant. 
This notion, however, is contrary to 
the notion of data sharing. Further- 
more, the approach that they devel- 
oped based on this relationship has sig- 
nificant practical drawbacks. 7 

Cosmadakis and Papadimitriou 8 
base their work on Bancilhon and Spy- 
ratos V notion of constant view com- 
plements. Their work primarily in- 
volves analysis, not general algorithms 
for view update translation. They 
show how difficult it is to use com- 
plements. (For example, they show 
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that finding a minimal complement of 
. a given view, is NP-complete.) They 
.adopt a universal relation assump- 
Hon 1 * ; that is, they see views as essen r , 
tially projections of a given relation.: 
'The implication of their work isthatan>. 
approach • d i f f ere n t . from const ant : 
compLwnts is needed. -.- 
V \ Hegner's approach, 14 also based 
on constant view complements of 
ty Bancilhon and Spyratos, attempts to 
. eliminate the ambiguity, by choosing 
particular complements, called * 'com- 
ponents." 

Carlson and Arora 15 ignore re- 
placement requests by claiming that 
they can be decomposed into a se- 
quence of Insertions and deletions. I 
believe that replacement requests are 
different from deletion and Insertion 
requests/ since they do not require a 
consistent database state between the 

" Furtadp, Sevcik, and dos Santos 16 
propose using the union operator for 
defining views and claim that Inser- 
tions, deletions, and replacements 
specified against a view defined by a 
union should be applied to each of the 
underlying merged relations in the 
database. The union operator is useful 
for distributed databases where a rela- 
tion is partitioned over several sites; 
however, where the relations are 
merged by the union operator, an in- 
sertion must occur at only one site and 
cannot be performed, as the authors 
suggest, at all sites. 

Genu ns, 17 Sevcik and Furtado, 18 
Rowe and Schoens, 19 and Tucher- 
mann, Furtado, and Casanova 20 all 
use an abstract data type approach to 
the view update problem. 

Masunaga 21 proposes the use of 
semantics for resolving ambiguity in 
the view update problem. He does not 
enumerate all possible translations, 
but rather an incomplete set of trans- 
lations—those that handle his class of 
updates. (He does not describe how 
these semantics are obtained ot exactly 
how they are used.) He also suggests 
that some ambiguity can be resolved 
by having the system ask questions of 



the user when the view update is re- 
quested. I suggest that all ambiguity be 
•/completely resolved by obtaining the 
- semantics at view definition time from 
the view definer ^typically the database; 
v administrator, so that no ambiguity re T 
: mains when users provide, view up : 
>v<dates. . - .-^ y ,>. . > 



Examples of update 
operations commonly: 
performed on : 
databases and views 

. .. The update operations on databases 
..and views that I consider below are 
deletion. Insertion, and replacement. 
A deletion is the removal of a single tu- 
ple from a relation . An Insertion is the 
addition of a single tuple to a relation/ 
A replacement is the combination of a 
deletion from and an Insertion into the ' 
same relation in a single, atomic action ■ 
that does not require a consistent in- 
termediate state between the deletion 
and insertion steps. An update is 
always either a deletion, an insertion, 
or a replacement. 

Let us consider an Employee rela- 
tion that contains each employee's 
name and location and tells whether 
the employee is a member of the com- 
pany baseball team. The company has 
two locations: New York and Austin. 
Baseball team members must be em- 
ployees. The database state follows: 



Her view state follows: 




The personnel manager in New 
York, Susan, has the following view 





**/cc"*frbin her view. A reasonable v v, V V 
" translation of this request is to delete : ^ * **. ' ■ ^ - ; 

Joe's enipioyee record from the under- ^ ^ U : ; 

lying database, that is, to translate a m -fy % : *\ 'I >> ' 
; view deiedon into a database defctfcm. : fjji ^ \ *« - 

if the employee was a member of the 

baseball team, he is thus removed 

from that membership as well. ^ , ^ , f ( 

The baseball team manager/Frank, 
/has the following view definition: ; 




His view state foltows: 




Suppose he requests deletion of 
"SaBy" from his view. It is unreason- 
able to delete the* *Saliy M employee tu- 
ple from the underlying database 
(unless one believes that baseball is all 
important). A reasonable translation 
of this view deletion request is to 
replace the Baseball attribute of the 
underlying database tuple with a 
"No," thus translating a Htm ikfc ti o o 
into a datttane repbeoML 

One might argue that Frank's view 
dektioa request should have been 
made in the form of a replacement 
However, this would mean requesting 
the replacement of a tuple (the "SaDy" 
tuple) in the view with a view tuple that 
does not appear in the view. Then 
Frank's request would not be vaBd in 
the view, as the replacement tuple 
could not possibly be a view tuple. In 
addition, Frank would have to make a 
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f m.,**.*,, t*v hi* view -.- 



dhiinc.iion between deletion and database to reflect employee reloca- 
that he cannot makc : by^m 



'On the other hand "the semantics of 



changing 
Se^b^^ 

A^requ^uW ™* '** ■ In for ^ 



the problem of stale data appearing on 
abuser's screen. - ^ 
^ ;'-The purpose of a shared database is 
to facilitate controlled interaction be- 




v rmulaimg a view describing the baseball 
team (like Frank's; 



shown above) 



change the under I yii^:. 'feu 
more than one way should be issued as, , 
^pia^ * valuer that of hot 

authorized to access the entire relation beu1g on ,he ,earn ' are wlwd * 
That person wouto r*^ acceav to a 
ivtet that f&mmvWng^all the effect^ 
n 6i* Auch a request 



^JWe veejhat a Vtew dekttbri requesi'u 



the new. Removing a record from the 
KaMcbali team view means changing 
^he database by either deleting the; ■ 
tmployee record Of changing -the -j 
»|E&sehaJi, team member # Held; t5irice>T 



tion between each view and the under- 
lying database;a problem thai is only 
linW in the numbe^ 
standing the interact ton bet ween each 
view ' and t he underlying database 
naturally leads to an understanding of 
the .interact ion between . views, -bur 
elaboration on the 4 subject is beyond 
the scope of this^icfe^ ^K^n h 

FaampK * of Joins. A further- level of 




«cruon requcsu, wtuch can be tram-; does not require choice ofa particular 
fated wtojtoito requests ; ^ah#e Tlw import of this observation 

and database replacement rtqitesu ■^■ufihat a replacerneru of a database tu- 
The two view* loii^ 



touon (Susan *« and Frank's) have the 
same syntactic structure, but differing 
semantic structures. Therefore, we can 
conctudr that semantic comideratkms 
alone are insufficient to disambiguate 
the view update problem. Let us con- 
sider some of the semantics nor cap- 
tured in the database and view defmi 
dons shown above that might be useful 

BP 



While the company may currently 
have two locations. New York and 
Austin, there are many other locations 
where the company could open up >of- 1 
fices. Thus, the location value "San 
FrandKD" might be selected from 
among many possible location values. 
To remove an employee from the New 
York office means a corresponding 
database change achieved by either 
(fcfctingtheempioyttrenxdOT 
mg the location in the record to Austin 
or S«n Francisco. In instances where 
there are many possible locations, 
changing location values in the 



is more likely to be desired when there 
is a single excluded value for an at- 
tribute mentioned in the Seka clause 
of the view definition. 

We can use Susan's and Frank's 
views to iterate r the nature of inter- 
action between users of different 
views. When Susan deletes Joe from 
her view. Joe also is removed from 
Frank's view. When Frank deletes Joe 
from the baseball team (and the origi- 
nal database state is thus changed), 
Joe's record in Susan's view is 
changed: He is shown as no longer on 
the baseball team. Such effects on 
other views may be somewhat discon- 
certing, but the same effects would oc- 
cur if the changes were requested on 
the underlying database instead of the 
view. Since afl operations on views are 
translated into operations on the data- 
base, a solution to the concurrency 
control problem on the database 
worts for the concurrency control on 
the view, although it does not handle 



tion and "department" is the key of * 
the DM relation, the EDM- view ls^ 
formed by the natural Join bet ween the 
ED and DM relations, and the EM 
view is abb formed by the natural jobs 
between the ED and DM relations, 
with the difference that the Depart- 
ment attribute is removed by a 
projection. 




COWUTR 





r 




f. 




<G2orgc,Ira> in the tame view by <fire^ 
<Oebr»e f Bofis>. W* cotdd ^ 

Boris the manager of the Male to^ dircrtkm, Tte type of join is 
paitmem, which wooM have t!^^^^ 

eftcatfetw^ dhe^ata^aS^?^ 
■^w^peM 0101*0^1*0 ao^ < 

EDM bir<C«^Miisi£^ 

This request require* i%plieiiig v frow • «W nwwtf jpte : 

<Mt*^>. TWs n*^ Myafcorfthms 

are itata independent ; the view definer 

decides what update* are to do to ad- has a personal computer at his dis- 

vance without consideration of the posal We cou&J delete the record of 

data, although the data is used to de? either the employ* or of the personal 

termine whether the update wiO suc^ oompu^ 
coed or fail, [[. ^ ^ 

%$tm the k$y of 

contained in one ""'^^g ^f?hfff ^ other vfew tanlesrocptkwiySmltb •?3 
relation, that relation fcils-jnipifjiii^ 



the ride effect of changing <Fred, 
Muafc4iB> to <F)red»Musfc,Ed0> 
as a result of the functional dependen- 
cy. If we refrse to permit the ride 
effect, we cannot accept the update. 
The presence of the attrftnrte in 
the view update request maker the 

• — 1 ~ r v inanflgfT ' in the ( 



Suppose that we want to delete the 
view tuple auertto* that employee 



•4 



abletoasktotueftoccm^ in one such relation, the 

ihtentionbal^tocha^themana^ fewest relations that contain the key/ 



of other employees in the Musk de- 
partment—in particular, Fred. Coft; 
flnnattonaffecutheuserinterfaceand 
not die algorithms for view update 
translation, so it is beyond the scope of 
this article. -V. T 

Let us consider some taserttai re-" 
quests and their consequences. Out- 
sider die request to insert <Rita, 
SaOy> into view EM. Is the desired 
department Art or Bodes? Consider 
the request to insert <RitaJra> into 
Vfcwipfc Wfecin atrony that the de- 
IWjtiiwj b MMCi but this is not jb*» 



are the root relations. Views that in- 
clude joins are more easily updated 
when there is a single root relation, 
f Let me first illustrate a view that has 
multiple root relations, and then show 
how to change this view so that it has 
only one root relation. 

Consider the following example, 
which involves a quay graph with two 
roots. We have three relations: Em- 
ployees, Projects, and Equipment. 
There is a many-to-ooe type of join, a 

f ■ n mm m\m m WWm ■ T 

rromtneno^- 



Smhb f s personal computer in the' 
Equipment relation will cause all 
tu^men itoning duu personal com- 
puter to disappear. We could delete 
both the employee and equipment 
tuples in question^ ^an approach sog— ^ 
gested by its symmetry), bin this would 
cause any view tuple that mentions 
either Smith or the perwwfll computer * 

toberemoved-^evenmoreundesr- 

— ■ j- *~ — » 
ante sue etrcct. 

In the f oBowiqg example, another 

relation, Uses, has been added to the 



sert <Rita*Boris> into view EM. We 



to the None attribute of the Projects 
relation, and also a reference connec- 
tion from the Project attribute of the 





t to replace <Geoqge, 
Ira >tn view EM by < George, 



lattaata^ 

^^m^^mm as wdL) 
';C^|w|ffie>r^e^ to replace 




nils relation shows exactly which 
» of equip- 

mem* Now we can dekte the view tu- 
ple asse r ting that employee Smith 
mm tne widget Design project nas a 
personal computer at his disposal, 
which is done by deleting the cor* 
responding tuple in the Uses relation in 




i ms VKV QCXDHDUD CKO vC OCeCPuBO 

by the following query staph* Each 
node represents a reuthm, and cadi 



These two examples Hhsteate why 
we only update through views that 
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•3! 

I 



te" ? for* 



v. ^ 




;->.-.i ;^^<Geot&Ata;> in .the -same yie^ by: greeted edge (indicated 'by the symbol 

>v^^.?< v C^ge^tic^.>. Weic^^ 

j-^W paitn^^wWch would have the' side . called an extension join, 23 and it arises.., • 
v V the database design; ** 

^ 0^ S^:?#f^^ itjs called a reference ] 

4 ^ ^ • v : , > 'partnwQtm^ J . : 

^t:Ut" us consider the request^ VI tSSS ^'- ' 

•:;:^^f#Iace <George;Music,Ira:* inview V.^ 1 wppmem <, ^ ;:/ 

M&*MPM by <Geoige,Music,Edo>: - f W^the.vJc^ ■ rt. ; :, 

• -;v£ , : ^f his request requires ". replacing- ;^^-f r «^?-^^n^' of-pW^v^^r ) ' ■ -rrr ■ 8 .--r^S*: 

^4 ) -V;<Music,Ira> -in relation DM. with -. . Jecttons, the view ^ update ; proWern te-^Supj^e that we want to delete the *. i 
^<Music,Edo>f This necessarily has comes data dependent, My algorithms* ■ ''view' tuple* asserting that employee ' ' " ; 
the side effect of changing <Fred, ^c data independent; the view definer Smith from the Widget Design project 
Music,Ira> to <Fred,Music,Edo> decides what updates are to do in ad- has a personal computer at his dis- 

T."".? ^cy/lf we refuse to permit the s^ v ;<f«a,;altl|i^*'the daU is;used to jfc?" ^.eilfer the employee or of to personal [ l \ ^ 
effect, we cannot accept the upc&teV; : 

' "ceedorfail. . ^AM.X - ; '.: *v :V; ii£the Employees idat»,':n«'oi#' ;\i/v : 5. 



7 ■**>-■ 



- -.V. :\??-;* 



;>3J>e presence of the ;Jotaratrtbutein/.;,-i-:-v. . 
. .^rj$ e ^cw update request ma>«\the^ V .When.th^^ 
* i"; ^user's intention clear: The user wishes" /contained in one underlying database' 
: i $ - Ceoirje^ rnanager < m v tfie f reMion.jj^'rck^ the roor /ete-J. 

r > - Y^^:;iyt iasic deparunemt. It wbuU be reason^ 

; i 1 ! i T ^'abte'to ask the user to confirm that the:, ly contained in one such relation; the 
i% - x ; ;^intenUonisaJsotocha^emer^^ fewest relations that;contain the key 1 
of other employees in the Music de- are the root relations. Views that in- 
" ^^partment--in particular, Fred. Con- : ^.clude f joins 'are^more^e^y^ui^cd^ 
, ;fW ation affects the user interface and when there is a i single root relation 
not the algorithms for view update 



translation, so it is beyond the scope of 
this article. 

Let us consider some insertion re- 
quests and their consequences. Con- 
sider the request to insert <Rita, 
Sally > into view EM. Is the desired 
department Art or Books? Consider 
the request to insert <Rita,Ira> into 
view EM. We can assume that the de- 
partment is Music, but this is not ne- 
cessarily so. Consider the request to in- 
sert < Rita,Boris > into view EM. We 
have no idea what department to use, 
since Boris is not already a manager. 

Let us consider some replacement 
requests and their consequences. Con- 
sider the request to replace < George, 
Ira>in view EM by < George, 
SaDy>. Should George be moved into 
the Art or the Books department, or 
should Sally become the manager of 
Music as wefl as Art and Books? (The 
tatter alteration has the side effect of 
c han gi n g Fred's nwnflgrr as well.) 
Consider the request to replace 
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Let me fust illustrate a , view that has 
multiple root re^tibr^/and then show 
how to change this view so that it has 
only one root relation/ 

Consider the following example, 
which involves a query graph with two 
roots. We have three relations: Ft. 
pioyees, Projects, and Equipment. 
There is a many-to-one type of join, a 
reference connection- from the Proj- 
ect attribute of the Employees relation 
to the Name attribute of the Projects 
relation, and also a reference connec- 
tion from the Project attribute of the 
Equipment relation to the Name attri- 
bute of the Projects relation. The view 
is defined by the following: 



all other view tuples mentioning Smithy ; 
.-^ah.uncteirableand arbh^aby sideetr ^ : : 
feet: Similarly, aeletin^.trte tur^ fw r 
Smith's personal computer; in \ the *> 
Equipment relation wUl cause, all v 
tuples mentioning that personal com- 
puter: to disappear: We could delete ^ 
both the employee and equipment 
tuples in question (an approach sug- 
gested by its symmetry), but Uus would 
cause any view tuple that mentions 
either Smith or the personal computer 
to be removed — an even more undesir- 
able side effect. 

In the following example, another 
relation, Uses, has been added to the 
view; 

C 



uses 



jE 



11 



t 



WWW, 



1 



projects 




This view definition can bet 

by the following query graph. Each 
node represents a relation, and each 



if 

This relation shows exactly "which 
employees use which pieces of equip- 
ment. Now we can dekte the view tu- 
ple asserting that employee Smith 
from the Widget Design project has a 
personal computer at his disposal, 
which is done by deleting the cor- 
responding tuptem the Uses rei 
the database. 

These two examples Otustrat* why 
we only update through views that 
have a single root relation. 



Dtafocjueatview 
definition time 



that the semantics necessary for disam- 
biguating view update translation be 
obtained at view definition time. The 
u v5-.v. j ^semantics should, then be used to 

£ V To iterate my design for up^ng, choose a view update translator, Once 
VftaUbasesi through views; I, propose. , . a traiulmor isch^ . 



■lr.<r; 



fi* ... 




Houel.Adata- 
base with the rota- 
tions "En?." and 
"Oept^dXfor 
which the views 
u NY M Mt M Basebeir 
and "Matties'" 
. (d) are defined. 



to 



. dates through 'he view, and the trans- 
lator converts these view updates into 
database updates without any addi- 
: tional disambiguating dialogue. I have 
Vprwqusly described the ciais pjf views 
and ;the view update transition' that 
my approach supports. 3 v/fc^?. r 
; In the discussion that follows. 1 
assume that the view is ckfuied by a 
database administrator (DBA) who, 
by making use of a view-deifinition 
facility, will also provide the necessary 
semantics to choose a translator. 
While the effort that the DBA : will 
need to make is the simplest case for 
the use of a view definition facility, it is 
dear that this system can be employed 
by any user with the wherewithal to 
define a view, either for the user 's ownt 
use or 'for the use of othCT^hapsless 
knowledgeable users. I regard the ef- 
fort of collecting the semantics at view; 
definition tfme as being amortized by * 
their subsequent use in many view up- 



V 1 \tr 



t 



The candidate translators are ^ organ- 
ized ccmceptuaUy into a tree, v^ierein 
each node represents a decision to be 
made. The semantics are merely the se- 
quence of decisions made by the DBA 
inawalk of this tree guided by the view 
definition faculty. The view definition 
facility presents questions to the DBA, 
each time supplying several options 
based on the view definition, the data- 
base schema, and the answers to the 
previous questions. Note that the tree 
of translators is different from the 
query graph representing the view. 
Note furthermore that the tree of 
translators is merely a pedagogical 
device; it does not actually exist within 
the view definition facility. 

C ho os in g a translator does not in- 
volve using any information about the 
transactions that win be performed 
against the view. This is because the 
translator chosen wffl take as input in- 
dividual view tuple updates and trans- 
late them mto sets of datab ase up* 
dates; Any Information contained in 
the nature of the transactions per* 
formed that is useful f or cfctennimng 
how to translate the update is captured 
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during the view definition dialogue. ... 
Since the set of transactions is not 
necessarily available at view definition ' 
tune, does hot contain all the informal 
. tiori needed for choosing a view update * 
translator, and at best provides the' 
same information that is obtained dur- 
ing the dialogue, I have chosen to use 
the dialogue to choose the translator 
instead. The algorithms that drive 
r the dialogue are fully described else- 
where.? 4 % 
. • The next three subsections illustrate. 
1 the dialogue for defining a view update" 
translator by arriving at translators for 
the three views ("NY," "Baseball, " 
land "Manages") given in Figure 1. In 
. that figure, a database state containing \ 
1 the relations '•Emp.". and "Dept.'; is 
.'followed • by three view definitions, * 
: each of which is followed by the cone- >. 
- sending view state. ~ , 

• Dialogue at view definition: dele- 
tion. Stylized examples of the dialogue 
are given below for each of the three, 
views. In each dialogue, the lines start- . 
ing with "VDF" indicate questions 
asked by the view definition facility,' 
and the lines starting with "DBA" in- , 
dicate answers given by database ad- 



NY view 

VDF: Is deletion of view tuples 

allowed? 

DBA: Yes. 

VDF: Does deletion of a view tuple 
mean deletion of the root database tu- 
ple, or replacement of that tuple? 
DBA: Deletion. 

VDF: OK, deletion of view tuples is 
now defined. Deletion of a view tuple 
means deletion of the corresponding 
database tuple. 



view 

VDF: Is deletion of view tuples 

allowed? 

DBA: Yes. 

VDF: Does deletion of a view tuple 
mean deletion of the root database tu- 
ple, or replacement of that tuple? 
DBA: Replacement. 



VDF: I assume that the baseball team 
field in the database tuple should be 
changed from "yes" to "no" when a 
view tuple is deleted. Is that correct? 

DBA: Yes , - 

.VDF: OK,, deletion of view tuples is 
now defined. Deletion of a view tuple 
means replacing the corresponding 
database tuple by changing the base- 
ball team field from Vyes" to "no." 

Manages view - ; . . v 

;VDF£. Is deletion of view tuples 
allowed? 
DBA: Yes. 

. VDF: OK, deletion of : view tuples is 
now defined. Deletion of a view tuple 
means deletion of the corresponding 
tuple from the Employee relation. 

Dialogue at view defiorapn: inser- 
tion. . . . ; • \" : ' ; . ' 

' NY view -•• 

VDF: Is insertion of view tuples 
allowed? : 
DBA: Yes. . 

VDF: If a new tuple is inserted with an 
employee name matching some em- 
ployee not in New York, should the 
employee location be changed to 
"New York," or should the request be 
rejected? 
DBA: Rejected. 

VDF: Can insertion of new view tuples 
cause insertion of new database 
tuples? 
DBA: Yes. 

VDF: On inserted tuples, what value 
should the baseball team have? 
DBA: "No." 

VDF: OK, insertion of view tuples is 
now defined. Insertion of a view tuple 
means insertion in the corresponding 
database tuple of location "New 
York" and baseball team "no." 

Baseball view 

VDF: Is insertion of view tuples 

allowed? 

DBA: Yes. 

VDF: If a new tuple is inserted with an 
employee name matching some em- 
ployee not on the baseball team, 



should be employee's baseball team 
field be changed to , 'yes," or should 
the request be rejected? \\- , # 

' DBA: Change. ? " ' *\ V; 

i VDF: Can insertion of new view tuples 
cause insertion of new database 
wples? ; v ^ ' v -j-i. - ; ; :< 5 .\ 
DBA: No rr ■ ; : : ' r \ . ! - 
VDF: OK 9 insertion of view tuples is 
now defined. Insertion of a view tuple 
means replacement of the correspon- 
ding Employee relation tuple by 

. changing baseball team to ''yes." Only 
employees in Employee relation but 
not appearing in view may be inserted 

Manages view . . ■ 

/VDF: Is insertion of view tuples 
allowed?-; r '"> * ' * : : 
DBA: Yes; , : *v, :! . 
VDF: Can insertion of new view tuples 

>cause insertion of new database tuples 
in the Employee relation? , V 

DBA:, Yes/ • : J V '<--\V ■'V*' 1 - ' 
VDF: On inserted tuples, what value 
should the baseball team have? 
DBA: "No." 

VDF: Can insertion of new view tuples 
cause insertion of new database tuples 
in the Department; relation? 
DBA: Yes. 

VDF: Can insertion of new view tuples 
cause replacement of existing tuples in 
the Department relation, for example, 
if the manager field differs? 
DBA: No. 

VDF: OK, insertion of view tuples is 
now defined. Insertion of a view tuple 
means insertion of the corresponding 
Employee relation tuple with baseball 
team value of "no" and, for a new 
department, insertion of the cor- 
respcmdmgr>partment tuple. The up- 
date wiD be rejected if a new employee 
is added with a different manager 
from the one already listed for an ex- 
isting department. 



Dialog it view definition: 



NY 

VDF: Is replacement of view tuples 

allowed? 

DBA: Yes. 
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V D F : * G a h . e m p 1 o y e e n a m e be 
changed? - - m > <*- 

'fVDF^.Cm^dip^taienl name: -be 

, ypFs'-OK-l replacement of view tuples' 
/ is now defined. Replacement of 
- department name wilt change the 
department name in^e^rir^^h'^juig' 
; Employee relation tuple. ^ - " ; ; 



* VDF: OK; replacement of view tuples 
is now defined. Replacement of a view 
■tuple will change. the corresponding 
sEmpjoyec re&uoh tuple if the depart- 
- <rnentr field changes, . will insert\a 
pepartmcm relation 'tuple for a new- 
• department, or will replace an existing 
: Department leLation tuple in the view 
update if the manager" tu'ffers from the 
manager of an exking ilepahment: t 



view ; u >• ■ 

VDF: Is replacement of view tuples 
aDowed? 

6 -"VDF: Can employee name :be : 
"changed? 

p^Yes? ^ - /: • '-+7. - ; 
• VDF:* ! assume that : the old ernployee 1 
:? ; has baseball teamVhanged to , **no/Vis' 

DBA' Vies" ■' < . 

' }VDF: I : a^nMhat toe nw employee: ; 

must be in v EmpIbyee relation and has 
. baseball team changed to -'yes." 

DBA: Yes';'^' 

VDF: OK, replacement of view tuples ' 
is now defmed • ^la^ment of em- : 
pk»yee name will change the database 
by changing the bid employee's 
baseball team to "no" and the new 
employee's baseball team to "yes." 
Only employees in the Employee rela- 
tion but not appearing in view may be 
replacements. 

Manages view 

VDF: Is replacement of view tuples 

allowed? 

DBA: Yes. 

VDF: Can employee name be 

changed? 

DBA: No. 

VDF: Can department name be 
changed for an existing employee? 
DBA: Yes. 

VDF: Can a new department be 
created in Department relation? 
DBA: Yes. 

VDF: Can manager be changed for an 
existing department? 
DBA: Yes. 



I ■ B have described a method that can 
| make updating relational databases 
8 through views reliable and conve- 
nient. The database administrator 
J. XDBA) defines the yiew and answe^a- 
, sequence of questions to choose a valid 
{view update translator for a large class 
of -.select, /project, and join views. The 
f definition /of the translator: is stored 1 
Raiting with r the view definition/ the 
' ;ciass of translators to* choose from is 
/ based 'oii the algorithm templates that' 
. generate all possible translations that 
satisfy five view-update-translation 
criteria. 3 K 
"'After the view and translator are 
defined, users can request insertions, 
deletions, and replacements through 
the view, and these are translated by 
the chosen translator into database up- 
dates, without the necessity for any 
disambiguating dialogue. Side effects 
can result from some insertions and 
replacements if permitted by the DBA; 
it may be desirable to have the user 
confirm such side effects, especially 
for insertions. 

Not all possible translators will be 
captured by the answers to the DBA's 
questions. The set of candidate view 
update translators is quite large; in an 
earlier work, 3 I characterized this set 
by enumerating the set of all view up 
date translations. Some of the trans- 
lators that will result from the ques- 
tioning will translate all updates that 
have translations satisfying the user's 
criteria; others will reject some updates 
because they were proscribed by the 
answers given by the DBA to the ques- 
tions asked by the view definition 
facility. The translators resulting from 
the dialogue are simple; in fact, they 



were used to generate the enumeration ~ V 
ohifelations. . / - . - 
; /^Tfe. Process of defining a view/ and; 
^oosmg a translator has bfm ^/ ^^i 
scri^ the* £>V r ' 

t^/WWle ^amount of work ; the v ; \ / 
DBA ivill need to perform is the sim- 
plest ca», for the use of a view npdate . v ? fl 
facility i it Vclear that ^^yJs^stei^caa ^ ^ ! ; 

al:td defined view.' The distinction to ; ; . \\ \ 
make.is that a dialogue used to seiect a ... /. 
;Aie\v^update:tra^ 
tive for static views that are defined 
once and used repeatrdjy. For dynam- 
ic views defined by natural language V; , 
disdogue or universal, relation inter£ / /'; > 
;,faces,^the overhead of answering the 'L . s 
/[questions is not amortized over time by; i { ^ 
\ performing . many .yiew' updates.^In? ^- . f *: ^ 
/such cases; heuristics abuser profile^' . , ; 
r^^ iised, tp^ de^rmme choice pf\^J}*~ %*] 
tractor. 8 / '"J \ r /«''' u [\ ". ' • ; : '*; v ?^* c '"' 1 

Querying and updating through a ^ i 
view reduces, the problems of security ^ r 
and protection, but does not eliminate 
them-/ Clearly,/ a /view circumscribes/^** 5' 
the collection vpf *data.. a user is...pe??*« ; 
mitted to accessOTe question of how' • 
togiveeachiharia^rac^stothea^^^ " 
for his or her department can be ad- 
dressed either by parameterizing the 
view to show only that department's 
data or by a parameterized protection 
scheme that allows the manager access 
only to tuples containing data for that 
department. Using both may seem re- 
dundant, but need not be. A parame- 
terized view will make fewer demands 
on the database and the security sys- 
tem. A security system would have a 
large loophole if it were to give special 
consideration to queries and updates 
specified through views. Of course, an. 
effective security system is needed 
when a view definition facility and an 
ad hoc query facility are made avail- 
able to users. 

With views and queries that are de- 
scribed non-procedurally, relational 
databases are an effective tool for 
productivity. 25 I have shown how to 
describe view update translators non- 
procedurally by answering a sequence 

COMPUTER 



... ry. vW ... , ■ 



• "1 




of questions based on the view defuii^^^'MBppings on Databases/' 1984 
tion and the database structure. This * ^ACM/Sigmod Intl Conf. Manage- 

rnon-pipceduraJdeOTptio Boston;" Mass.; 'June 

j flSr potehtto, to toanuulcaiiy 

!4he prb)juc^ ^l£L&#M<s&&>>'rk 
quendyi bf relational databases 

'Updates to, Relational' 
Through Views Involving 

;■>«« . t jhiii^,»a-ib improving Database ' 

mann/Ghnstos Papadirait™^^ and Responsiveness, R 

RicliardShu^ Academic Press, 

..•couragement:>J ; - . i' York, 1982. . 

: This work was supported in Jjarjp^jgo^ and M A. Casanova, 

Contract N39-84-C-G21 1 (the Kiiowl- * "Updating Relational Views," in 
edge Base Management Systems Pro- Query Processing in Database 
ject, ProfessOT.GioW^ n S. Reiner and 

.qpal Jiiv^^ Spr^ger-Vertag^ 

^anced ; Research P^jec^ Je t „ , 

contained, in it are those^of the autHor phases: Intcrpretanon of Update Re- 
'.; and should not be interpreted as ^.repre-Vt^^SuestSi?- Proc. Seventh IntU Joint 

t :B:C. f Canada, Aug; 1981. 



r$9 a tu- Managemen t of -. Data, , +?r. ^ & , - • 
(IGMOD). Maan;.Itaiv: Jim* tQT* ; : tf^'V 




. Kaplan and J. Davidson, "Inter-" 
. preting Natural Language Database 
References 17 ^ ^ - - ^Ujklates,"/*oc. 19th Annual Meet- 

ingof the Association for Cqmputa- . 
r. ^fr.i> r ^ Stanford,' Calif.;' 

1. F. BancUhonjind^fsi^ 



20. 
21- 

, 22; 

r 23. 

25; 



M. Av GasamMV!«AtI*4*n^'tt^^ • J*. • • ».*V / * ■ * 



" M; : Av .CasanovaitVAifirag^ . 

:•* prbach:. m . structu^ i^V-— . " 

.si^y/^Y/^ 

Rorence, Italy; Oct. 1983. T^V 
V;;^bsunaga; ' ; 'A* Rdanoitf;^^fv; . 
base TiewUpc^:^ - 
anism," Report RJ3742, IBM San 
Jose Research Laboratory, San Jose, 

G: WiederhoU;Ztoto6a»/3^ A'-s^S A .V 
ed^McGraw^^ 

P^Hoiieyman. 'Extenswn^bm*/? 
'Prbc^intXiConf^ Veryyij^vDmaVW^ 
Bases, Montreal 1980 * , ;V 

^^.•keDer^iVGhc^ V 1 *^ 
aate :Translator;by : Dialog at View- 
Definition time/* submitted for piitf /r^ 
fican'on. .^ . : , s . ; •V.V>2-V>;i.'^.- 

E. F. Codd, ^Relational Database: A'f s - ® 
Practtcal Foundation for Productivi- 
ty," Comm. ACM, Vol. 25;Nb. :; i r r>^V 
Feb. 1982:" ^ - ' - ^. :.;v; 



•"Update Semantics {and Relational - 
Views," ACM~Traw$Database Sy&J, 
terns, Vol. 6', No. 4; Da^l981. • . < 
2. U. Dayal and P. A; Bernstein, •'On ' 
the Correct Translation of Update 
Operations on Relational Views," 
ACM Trans, Database Systems, Vol. 
7, No. 3, Sept. 1982. 

J. A. M. Keller. M Algorithms for 
Translating View Updates to Database 
Updates for Views Involving Selec- 
tions: Projections, and Joins," Proc. 
fourth ACM Sigact-Sigmod Syrup. 
Principles of Database Systems, Mar. 
1985. 

4. "Final Report c: the ANSI/XJ/ 
SPARC DBS-SG Relational Database 
Task Group," M. Brodie and J. 
Schniidt,eds.,mS%im^/feconf,Vol. 
12, No. 4, July 1982. 

5. D. Maier, Theory of Relational 
Databases, Computer Science Press, 
Rockvffle, Md., 1983. 

6. J. D. Ulbnan, Principles of Database 
Systems* 2nd ed., Computer Science 
Press, Rockvffle, Md., 1982. 

7. A. M. Keller and J. D. UQman, "On 
Complementary and Independent 

January 1986 



J^P. ' UIlman, "The U.R. Strikes 
• Back," in Proc. ACMSymp. Prin- 
I cipies of Database Systems, Los 
* Angeles, Mar. 1982. 

14. S. J. Hegner, "Canonical View Up- 
date Support Through Boolean Alge- 
bras of Components," Proc. Third 
ACM Sigact-Sigmod Symp. Princi- 
ples of Database Systems, Apr. 1984. 

15. C. R. Carlson and A. K. Arora, "The 
Updatability of Relational Views 

<• Based on Functional Dependencies," 
Third Int'l Computer Software and 
Applications Conf, ( IEEE Computer 
Society). Chicago, ID., Nov. 1979. 

16. A.L.FurtadcsK.C.Sevdk,andC.S. 
t dos Santos, "Permitting Updates 

# Through Views of Data Bases," Infor- 
mation Systems, Vol. 4. No. 4, 
Pergsmon Press, Ehnsford, N.Y., 
1979. 

17. E. K. demons, "An External Schema 
Faculty to Support Data Base Up- 
dates," in Databases: Improving 
Usability and Responsiveness, 
Academic Press, New York, 1978. 

18. K. C. Sevrik and A. L. Furtado, 
'•Complete and Compatible Sets of 




Arthur M. Keflcr is an assistant professor of 
computer sciences at the University of 
Texas at Austin. He has lectured widely on 
databases, distributed databases, and com- 
puterized typesetting. He is the author of A 
First Course in Computer Programming > 
Using Pascal (McGraw-Hill, New .York, 7 
1982). 

Kefler received his PhD from Stanford 
University in 1985. His thesis was tftM t 
"Updating Relational Databases Through 
Views." He received his MS from Stanford 
and his BS from Brooklyn College 
(CUNY). 

Questions about this article can be di- 
rcctcj to Keferp*!he University of Texas at 
Austin, Dep.. of Computer Sciences, 
Austin, TX 787 1M 188. 

. 73 



